Network Reference Models

In this guided exercise, you will take a look at the TCP/IP and OSI model layers through the Wireshark protocol analyzer. Wireshark will display all the encapsulated portions of a packet in its Packet Details pane. However, it does not conform to either the TCP/IP or OSI model, but rather a combination of both. 

Namely, it only combines layers 5-7 (Application, Presentation, Session) of the OSI model, leaving alone layers 1-2 (Physical and Data Link, as opposed to combining them into a Network Access layer as in the TCP/IP model). Let’s add that detail to the diagram you previously viewed so you get the full comparative picture.

It’s also important to note that Wireshark will list these layers of encapsulation with the lower layers at the top (Physical, Data Link), and the higher layers at the bottom (Application). 

Alright – enough chit chat. Open the Packet Capture and get busy.

1. From the Desktop, double-click the Practice.pcpng file to launch this lesson's Packet Capture in Wireshark.
   

   

   The Packet List pane (top) and the Packet Details pane (middle) are the ones you’re interested in. You’ll select packets from the Packet List, and inspect its encapsulated layers in the Packet Details pane.
   
   Go ahead and remove the Packet Bytes pane from your view to free up some real estate.
   
2. From the Wireshark menu, select View > Packet Bytes to remove the Packet Bytes pane from your view.
   

   

   First disclaimer: Know that the term ‘packet’ is used liberally in Wireshark to refer to the data units captured for inspection, regardless of whether the ‘packet’ has any of the headers and trailers associated with the same-named PDUs at the Internet/Network layers. Gotta call it something to be consistent, so packet it is!
   
3. In the Packet List view, select the first broadcast packet in the list.
   

   

   You’re looking at a wireless Packet Capture. These beacons are the broadcast messages sent out by a Wireless Access Point (WAP) to advertise its network. We’ve selected a Wireless capture because it will provide information about the Physical layer. If this were captured on a wired interface, Wireshark would begin with the Data Link layer (2), because this is the layer at which Wireshark decodes packets captured over the wire (as opposed to over-the-air).
   
4. In the Packet Details pane, double-click the Frame row (top) to expand it.
   

   

   Second (last) disclaimer: this “Frame” section will be included in every packet, and does not correspond to the Frame PDUs that switches forward over the Data Link layer in a local network. Rather, this is a special Wireshark meta-layer that contains details about the packet. This include useful information like:
   
   Encapsulation type –  this refers to the top-layer header present in the packet. By “top”, this refers to the lowest layer in OSI and TCP/IP terms, that is available in the packet. This makes sense if you remember that traveling down the stack (sending data, aka encapsulation) means adding additional details to the packet.
   
   Protocols in frame – contains a colon-separated list of all protocols contained in this packet. In this case, you can see it contains information about the radio transmission (the Physical Layer) and about the 802.11 WLAN protocol (the Data Link Layer). These are displayed left-to-right from the lowest to the highest protocol layer found in the packet. You can inspect these protocols in the rows below.
   
5. Double-click the Frame row to collapse it, then double-click the Radiotap Header v0 row to expand it.
   

   

   This contains Physical Layer information, such as the data rate, the strength of the antenna signal in decibel milliwatts (dBm), the channel being used, and the frequency. You can see this broadcast packet advertises a network over the 2.4GHz layer, the most common frequency for Wi-Fi networks (the other being the less-crowded 5GHz).
   
6. Double-click the Radiotap Header v0 row to collapse it, then double-click the 802.11 radio information row to expand it.
   

   

   This layer contains much of the same (Physical Layer) information displayed in the previous one, although is slightly more readable.
   
7. Double-click the 802.11 radio information row to collapse it, then double-click the IEEE 802.11 Beacon frame row to expand it.
   

   

   Now we’re on to the Data Link layer. The giveaway? Look at those destination and source MAC addresses, those address identifiers found in the headers of Frames, used by switches to forward data to its destination on the local network. You’ve got a broadcast address as destination (the highest possible MAC address, since FF is the largest value in hexadecimal), and the MAC address of the transmitting network card on the WAP.
   
   Take note of the MAC address for the transmitter. You will need it to answer one of the questions on the Tasks tab.
   
8. Double-click the IEEE 802.11 Beacon frame row to collapse it, then double-click the IEEE 802.11 Wireless Management row to expand it.
   

   

   Similar to the radio rows, this row contains much of the same information contained in the previously inspected lower layers. One additional piece is the Beacon Interval, which refers to the frequency at which these beacons are broadcast.
   
   No more layers to inspect in these packets, as these simple Beacon Frames contain no higher-layer information. Let’s move on to a packet that contains some additional layers.
   
9. In the Wireshark display filter bar, type tcp to show only packets with TCP.
   

   

   Looking at the Protocol column in the Packet List Pane, notice you can see TCP packets, as well as some HTTP packets in the list. That’s because both contain TCP information. Specifically, HTTP packets, which contain higher-layer Application Layer details, are encapsulated by the layers below it, including the Transport layer (and specifically TCP), so naturally they contain all the lower-layer dependencies.
   
10. Select the first HTTP packet in the list (No. 841).
    

    

    Behold - the same layers you saw in the Beacon packet, in addition to the lower layers that wrap up (encapsulate) the HTTP protocol. From top-to-bottom, you’ll find:
    
    Physical Layer (Radio Information)
    Data Link Layer (IEEE 802.11 and Logical-Link Control Information)
    Internet/Network Layer (Internet Protocol Version 4)
    Transport Layer (Transmission Control Protocol, aka TCP)
    Application Layer (Hypertext Transfer Protocol)
    
11. Double-click the Internet Protocol Version 4 row to expand it.
    

    

    A couple interesting Network/Internet Layer details can be found here, such as:
    
    Source and Destination IP addresses – you know, those logical identifiers of the Internet/Network Layer.
    Protocol – the Transport Layer Protocol it has encapsulated (TCP).
    
    Neat! Take note of the destination IP address. You will need it to answer one of the questions on the Tasks tab, along with the port number, which you can find in the next step. Now let's continue moving up the stack and check out that encapsulated Transport Layer protocol.
    
12. Double-click the Internet Protocol Version 4 to collapse it, then double-click the Transmission Control Protocol row to expand it.
    

    

    Remember, this layer is the province of ports! You can see the destination port (a common port for HTTP, or unencrypted web traffic), and the source port (a random one chosen by the sending application). You also see sequence and acknowledgement numbers, which help TCP track the transmission for error-checking, delivery guarantees, and reassembly at the other end. How reliable!
    
13. Double-click the Transmission Control Protocol row to collapse it, then double-click the Hypertext Transfer Protocol row to expand it.
    

    

    You’ve reached the top layer of abstraction, the old and venerable HTTP. Here you’ll find the HTTP request made (GET / HTTP/1.1, aka get the hypertext document at the root of the web site, using HTTP version 1.1) in addition to the full host URI in the form of protocol://ip-address:port.
    
    Okay, almost done – you’ve reached the top layer of this packet, but this was just an HTTP request. For an HTTP response, data will be sent as well (that data being the content of the web page), which Wireshark will add as another Application Layer. Check that out before closing this section out.
    
14. In the Packet List pane, select the second HTTP packet (no.844) to view the HTTP response.
    

    

    Okay, so there are actually two new details here: an additional Transport layer row that notes the TCP segments that were reassembled, and the aforementioned new Application layer that contains the data sent back to the client.
    
15. In the Packet Details pane, double-click the Line-based text data row to expand it.
    

    

    There it is – the human-generated message that was sent down the stack for encapsulation into the lower layer PDUs for sending over-the-air, then sent back up the stack to peel away (decapsulate) those additional layers of information, ultimately revealing the message contained therein to the client. What a trip!
    
    Take note of the "flag" in the Application layer data. It's contained in {brackets} - a common convention for flags in Capture the Flag style challenges. You'll need it to answer one of the questions on the Tasks tab.
    
    You’ve made it! Be sure you've answered the questions on the Tasks tab, then move on to the Challenge Exercise to really test your mettle by taking on a similar capture all by your lonesome.